Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 1/csmp-v1-182.txt

Text File | 1992-12-31 | 52KB | 1,432 lines

C.S.M.P. Digest             Sat, 10 Oct 92       Volume 1 : Issue 182

Today's Topics:

    Password entry in a dialog
    DLOG stuff....
    Using CODE rescource files
    Moving to the foreground after receiving an 'odoc' from the Finder



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Paul Taplin)
Subject: Password entry in a dialog
Date: 29 Jun 92 09:36:00 GMT
Organization: Department of Architecture, University of Adelaide

I need to allow password entry into an editText field of a dialog. I'm
wondering if the best way to hide the entered text is to use a font
consisting of 'bullets' (option-8's) only, instead of replacing each
keystroke with the value of a 'bullet'.
Using a font of all bullets would allow me to specify any field as
being hidden data entry, and means that I can let TextEdit do all the
work constructing the strings. If I were to replace the characters as
they were being entered then I'd need to construct strings holding the
actual text (which might be a little complicated should the insertion
point be changed, etc.)
Am I on the right track? Has anyone any suggestions?

Thanks,

Paul.
- --
| Paul Taplin                   Phone: [phone]                         |
| Postgrad Student              Fax:   [phone]                         |
| Department of Architecture    Email: [e-mail]           |
| University of Adelaide        Postal:GPO box 498,Adelaide SA 5001,Australia |

+++++++++++++++++++++++++++

From: [e-mail] (Martin Minow)
Date: 29 Jun 92 14:05:45 GMT
Organization: Apple Computer Inc., Cupertino, CA


[e-mail] asks about putting passwords into
dialogs.  There are two basic solutions:

1. Create a font with *no* characters and set the "unknown character" to
   "bullet" and use this font to display your text. You can use the
   SetDAFont call to set the font -- but then must create userItems to
   store all static text.
2. Trap keyboard and edit (cut/paste) events in the ModalDialog filterproc
   hide the text in a private record, and substitute the bullet character.
   This is tricky to do if you handle cut/paste.

I found that the first solution worked best for me. Note that your
font must have a number in the application-private range. I used 32400
for the FOND/font family, and 32412 for the font id.

Good luck.

Martin Minow
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Mel Walker)
Organization: Novell, Inc. - Walnut Creek
Date: Mon, 29 Jun 1992 16:25:13 GMT

In article <[e-mail]> [e-mail] (Martin Minow) writes:
>
>[e-mail] asks about putting passwords into
>dialogs.  There are two basic solutions:
>
>1. Create a font with *no* characters and set the "unknown character" to
>   "bullet" and use this font to display your text. You can use the
>   SetDAFont call to set the font -- but then must create userItems to
>   store all static text.
>2. Trap keyboard and edit (cut/paste) events in the ModalDialog filterproc
>   hide the text in a private record, and substitute the bullet character.
>   This is tricky to do if you handle cut/paste.
>
>I found that the first solution worked best for me. Note that your
>font must have a number in the application-private range. I used 32400
>for the FOND/font family, and 32412 for the font id.
>
>Good luck.
>
>Martin Minow
>[e-mail]

What about spaces? Won't they always print as a space, no matter what the
"unknown character" is in the font? On the DevCD, there was a set of password
routines, one of which used two edit text items in a dialog, one of which
was hidden. It works well, handles spaces, mouse selection, etc.

- --
Mel Walker                     "You can't have everything...
[e-mail]         where would you put it?"
Novell Macintosh Test Team              -- Stephen Wright

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 29 Jun 92 17:56:44 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (Martin Minow) writes:
>[e-mail] asks about putting passwords into
>dialogs.  There are two basic solutions:
>
>1. Create a font with *no* characters and set the "unknown character" to
>   "bullet" and use this font to display your text. You can use the
>   SetDAFont call to set the font -- but then must create userItems to
>   store all static text.

Does this mean that the warning on page 230 of IM-I (Font Manager chapter)
no longer applies?  I quote:

    WARNING: Every font _must_ have a missing symbol.  The characters
    with ASCII codes 0 (NUL), $09 (horizontal tab), and $0D (Return)
    must _not_ be missing from the font if there's any chance it will
    ever be used by TextEdit;  usually they'll be zero-length, but you
    may want to store a space for the tab character.

This seems quite emphatic to me.  I'm concerned in light of the fact that
the Dialog Manager uses TextEdit for all static and editable text items.
What's the scoop?

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Thad Humphries)
Date: 30 Jun 92 03:16:23 GMT


  PT> From: [e-mail] (Paul Taplin) Newsgroups:
  PT>
  PT> I need to allow password entry into an editText field of a dialog. I'm
  PT> wondering if the best way to hide the entered text is to use a font
  PT> consisting of 'bullets' (option-8's) only, instead of replacing each
  PT> keystroke with the value of a 'bullet'....

There is an example by a guy from the UK DTS office on the d e v e l o p CD.
He shows three approaches and explains each:  unique font, edit an off screen
text field and paste in bullets on screen, and a 3d I don't recall.  I just this
Saturday did it a 4th way with globals (sorry professor).  I'm sure I can tweak
this down to be a bit more flexible, but at 2AM Sunday morning, ya gets what you
can get.  Here is the dialog filter proc:

// For trapping the password and outlining the OK button in the first dialog.
pascal Boolean LoginDLOGFltr( DialogPtr theDialog, EventRecord *event, short
*itemHit )
{
    short    itemKind, radius;
    Handle    itemHandle;
    Rect    itemRect;
    char    key;
    Handle    nameTextHandle, pwTextHandle;
    Str255    nameTextStr, pwTextStr;

    GetDItem( theDialog, kNameItem, &itemKind, &nameTextHandle, &itemRect );
    GetDItem( theDialog, kPWItem, &itemKind, &pwTextHandle, &itemRect );
    GetIText( nameTextHandle, &gName );
    GetIText( pwTextHandle, &pwTextStr );

    switch ( event ->what ) {
        case keyDown:
        case autoKey:
            key = ( event->message & charCodeMask );
            switch ( key ) {
                case chReturn:
                case chEnter:
                    if ( (gName[0] >= kMinLength) && (pwTextStr[0] >= kMinLength) ) {
                        *itemHit = kOKBtn;
                        FlashDialogItem( theDialog, *itemHit );
                    }
                    return TRUE;
                case chPeriod:
                    if ( event->modifiers & cmdKey ) {
                        *itemHit = kCancelBtn;
                        FlashDialogItem( theDialog, *itemHit );
                        return TRUE;
                    }
                case chEscape:
                    *itemHit = kCancelBtn;
                    FlashDialogItem( theDialog, *itemHit );
                    return TRUE;
                case chTab:
                    return FALSE;    // for normal dialog behavior of a tab
                case chSpace:
                case chNBSpace:  // non breaking space
                    SysBeep(1);
                    return TRUE;    // no spaces in name or password
                default:
                    // If we're in the password field...
                    if ( ((DialogPeek)theDialog)->editField + 1 == kPWItem ) {
                        // ... and the user didn't backspace,
                        if ( key != chBkSpace) {
                            if ( pwTextStr[0] == kMaxLength ) {
                                SysBeep(1);
                                return TRUE;
                            }
                            // put the key into the password global...
                            gPassword[0] = pwTextStr[0] + 1;
                            gPassword[ pwTextStr[0] + 1 ] = key;
                            // ... and return him a bullet.
                            event->message = chBullet;  // the option-8
                            DialogSelect( event, &theDialog, itemHit);
                        }
                        // If he did backspace in the password field ...
                        else {
                            // ... adjust the password strings ...
                            gPassword[0] = gPassword[0] - 1;
                            // ... and let TextEdit take over.
                            return FALSE;
                        }
                    }
                    // If we're in the name field, process the key normally.
                    else {
                        // Allow for backspacing.
                        if ( key != chBkSpace ) {
                            if ( gName[0] == kMaxLength ) {
                                SysBeep(1);
                                return TRUE;
                            }
                            DialogSelect( event, &theDialog, itemHit);
                        }
                        else
                            return FALSE;
                    }
                    return TRUE;
            }
        // Outline the OK button.  From "Macintosh Programming Secrets, 2 ed.", p.
164.
        case updateEvt:
            SetPort( theDialog );
            GetDItem( theDialog, kOKBtn, &itemKind, &itemHandle, &itemRect );
            InsetRect( &itemRect, -4, -4 );
            radius = ( itemRect.bottom - itemRect.top ) / 2;
            if ( radius > 16 )
                radius = 16;
            PenNormal();
            PenSize( 3, 3);
            FrameRoundRect( &itemRect, radius, radius );
            return FALSE;
        default:
            return FALSE;
    }
    return FALSE;
}

God! He comments his code well!

+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Date: 1 Jul 92 02:53:41 GMT
Organization: NCRPDA, Curtin University

In article <[e-mail]>, [e-mail] (Martin Minow) wrote:

> 1. Create a font with *no* characters and set the "unknown character" to
>    "bullet" and use this font to display your text. You can use the
>    SetDAFont call to set the font -- but then must create userItems to
>    store all static text.

My experience doing this was not so good - no matter what I did to the font
the space character always appeared as a space and never a bullet.  Is it
just me?  Probably :-)

> 2. Trap keyboard and edit (cut/paste) events in the ModalDialog filterproc
>    hide the text in a private record, and substitute the bullet character.
>    This is tricky to do if you handle cut/paste.

Here is some pascal code that will get you started, its by no means
perfect, it doesnt handle cmd-keys, edit menus, moving the window,
outlining the default button or anything else.

program Passwords;

 const
  ok_item = 1;
  name_item = 2;
  password_item = 3;

 procedure Getitemtext (dlg: dialogPtr; item: integer; var s: str255);
  var
   k: integer;
   r: rect;
   h: handle;
 begin
  GetDItem(dlg, item, k, h, r);
  GetIText(h, s);
 end;

 var
  dlg, thedlg: dialogPtr;
  theitem: integer;
  quitNow: boolean;
  er: eventRecord;
  name, pass, tes: str255;
  dummy: boolean;
  dest, view: rect;
  teh: TEHandle;
  ch: CharsHandle;
begin
 dlg := GetNewDialog(128, nil, POINTER(-1));
 SetRect(dest, 10, 10, 100, 20);
 view := dest;
 teh := TENew(dest, view);
 repeat
  dummy := WaitNextEvent(everyEvent, er, 10, nil);
  if IsDialogEvent(er) then begin
   if er.what in [keyDown, AutoKey] then
    if dialogPeek(dlg)^.editField + 1 = password_item then begin
     TESetSelect(dialogPeek(dlg)^.textH^^.selStart,
dialogPeek(dlg)^.textH^^.selEnd, teh);
     TEKey(chr(BAND(er.message, charCodeMask)), teh);
     if BAND(er.message, charCodeMask) >= 32 then
      er.message := BAND(er.message, $FFFFFF00) + $A5;
    end;
   if DialogSelect(er, thedlg, theitem) then begin
    if theitem = 1 then
     quitNow := true;
   end;
  end;
 until quitNow;
 GetItemText(dlg, name_item, name);
 GetItemText(dlg, password_item, pass);
 ch := TEGetText(teh);
{$R-}
 tes[0] := chr(teh^^.teLength);
 BlockMove(ptr(ch^), @tes[1], teh^^.teLength);
 TEDispose(teh);
 DisposDialog(dlg);
 ShowText;
 writeln('Name:', name);
 writeln('Password: ', pass);
 writeln('Pass2:', tes);
end.

Have fun,
   Peter.

_______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University       [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA             FAX: [phone]

+++++++++++++++++++++++++++

From: [e-mail] (Tom Dowdy)
Date: 2 Jul 92 15:57:59 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Martin Minow) wrote:
> [e-mail] asks about putting passwords into
> dialogs.  There are two basic solutions:
>
> 1. Create a font with *no* characters and set the "unknown character" to
>    "bullet" and use this font to display your text. You can use the
>    SetDAFont call to set the font -- but then must create userItems to
>    store all static text.
> 2. Trap keyboard and edit (cut/paste) events in the ModalDialog filterproc
>    hide the text in a private record, and substitute the bullet character.
>    This is tricky to do if you handle cut/paste.

3. Install QuickDraw bottlenecks in your dialog for StdText and
StdTextMeas,
when each character comes through, sub for the '*' character.  The
only difficult part is determining if the thing being drawn or measured
is in the text item you are interested in.

You can also use this method for drawing boxes that are the same width
as the characters, or for having a "filling bar" for the password
(a la MacX).

 Tom Dowdy                 Internet:  [e-mail]
 Apple Computer MS:81KS    UUCP:      {sun,voder,amdahl,decwrl}!apple!dowdy
 20525 Mariani Ave         AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

From: [e-mail] (Christophe Meessen)
Date: 3 Jul 92 10:38:39 GMT
Organization: Universite Catholique de Louvain (Belgium)

In article <[e-mail]>, [e-mail] (Martin Minow) wrote:
> [e-mail] asks about putting passwords into
> dialogs.  There are two basic solutions:
>
> 1. Create a font with *no* characters and set the "unknown character" to
>    "bullet" and use this font to display your text. You can use the
>    SetDAFont call to set the font -- but then must create userItems to
>    store all static text.
> 2. Trap keyboard and edit (cut/paste) events in the ModalDialog filterproc
>    hide the text in a private record, and substitute the bullet character.
>    This is tricky to do if you handle cut/paste.

I shoosed the second solution. But we get problems if we want to handle
arrow keys, mouse selection, delete key etc.

What I did is creating one editable visible field which has its TEdit
structure.
I created a second TEdit structure but in a rect outside the screen.

If a Key dow event occured, I stored the char in the invisible TEdit
structure and stored a bullet in the visible TEdit structure.
Arrow keys and delete keys behaved the same way in both structures.

When a mouse down event occured in the visible TEdit structure I just
copyed the cursor position (SetSelection) in the invisible TEdit structure.

So what ever event would come next, the both fields would remain
consistent.

The resuslt was a real masked password field.

This was added to a visible userName field in the same dialog.

Hope this idear may help some of you out there.

I can post the source code of my password dialog box module on usnet if
asked.

Bien cordialement,

                           Christophe MEESSEN

+++++++++++++++++++++++++++

From: [e-mail] (Bertrand Limoges)
Date: 10 Jul 92 13:34:38 GMT
Organization: Sobeco Ernst & Young

In article <[e-mail]>, [e-mail] (Martin Minow) wrote:
> [e-mail] asks about putting passwords into
> dialogs.  There are two basic solutions:
>
> 1. Create a font with *no* characters and set the "unknown character" to
>    "bullet" and use this font to display your text. You can use the
>    SetDAFont call to set the font -- but then must create userItems to
>    store all static text.
> 2. Trap keyboard and edit (cut/paste) events in the ModalDialog filterproc
>    hide the text in a private record, and substitute the bullet character.
>    This is tricky to do if you handle cut/paste.

I used the second option, and was inspired by a snippet of code from UMPG,
which I include below. I rewrote it in C, and avoided using a global to
store the actual password by stuffing a handle to the password string in
the dialog's RefCon. All you have to do in your dialog filter is to retrieve
the handle using GetWRefCon.

Hope this helps, Bertrand Limoges, Montreal, Canada

disclaimer: opinions expressed are definitely my own!


>From: [e-mail] (.i.Brian Bechtel;)
Subject: Re:.c2. Password a'la AppleShare (Dialog Filter with code)

I kept this code from the last time that this question was asked.
>From: [e-mail] (Jim Matthews)
>Subject: Re: suppress display of password entry

In article <[e-mail]> [e-mail] (Wade Blomgren) writes:
>
>What is the best (easiest) way to allow entry of a password on the screen
>while suppressing the display of the actual characters in the
>edittext item?

It actually isn't very difficult to intercept the key events and keep a hidden copy of the password string.  It isn't necessary to remember any context since you have access to the TextEdit record, and it tells you what the current selection is.  The following routine is a filter for a name/password dialog box.  It displays bullets (ala AppleShare) and stores the real password in a global string, pwStr.  It also handles hitting return or enter.

{ signonFilter -- dialog filter for doSignon, hides password }

FUNCTION signonFilter (dp : DialogPtr;
            VAR theEvent : EventRecord;
            VAR itemHit : integer) : boolean;
    CONST
        nameItem = 3;
        passwordItem = 4;
        bs = $08;
        tab = $09;
        cr = $0D;
        enter = $03;
        larrow = $1C;
        rarrow = $1D;
        uparrow = $1E;
        downarrow = $1F;
    VAR
        dpeek : DialogPeek;
        theChar : char;
        theStr : Str255;
        selStart, selEnd : integer;
        h : Handle;
        itemType : integer;
        box : Rect;
BEGIN
    signonFilter := false;
    dpeek := DialogPeek(dp);
    IF ((theEvent.what = keydown) OR (theEvent.what = autoKey)) THEN
        IF (dpeek^.editField = passwordItem - 1) THEN
        BEGIN
            theChar := char(BitAnd(theEvent.message, charCodeMask));
            selStart := dpeek^.textH^^.selStart;
            selEnd := dpeek^.textH^^.selEnd;
            CASE ord(theChar) OF
                bs :                { Backspace }
                    BEGIN
                        IF selEnd = selStart THEN  { back over a character }
                        BEGIN
                            IF selStart > 0 THEN
                             pwStr := concat(copy(pwStr,1, selStart - 1),
                                                  copy(pwStr, selStart + 1,
                                                   length(pwStr) - selStart));
                        END
                        ELSE            { delete the selection }
                            pwStr := concat(copy(pwStr, 1, selStart),
                             copy(pwStr, selEnd + 1,
                                   length(pwStr) - selEnd));
                    END;
                cr, enter :     { Return or Enter -- treat as "OK }
                    BEGIN
                        itemHit := ok;
                        signonFilter := true;
                    END; { cr, enter }
                tab, uparrow, downarrow, rarrow, larrow :
                    ;     { just pass on tabs & arrows }
                OTHERWISE   { "normal" character }
                    BEGIN        { remember character, insert a bullet }
                        pwStr := concat(copy(pwStr, 1, selStart),
                         theChar,
                         copy(pwStr, selEnd + 1, length(pwStr) - selEnd));
                        theEvent.message :=
                         BitAnd(theEvent.message, $FFFFFF00) + ord('%');
                    END; { normal character }
            END; { case ord(theChar) of }
        END { in password field }
        ELSE     { not in password field -- still check for cr, enter }
            CASE BitAnd(theEvent.message, charCodeMask) OF
                cr, enter :
                    BEGIN
                        itemHit := ok;
                        signonFilter := true;
                    END; { cr, enter }
                OTHERWISE
                    ;
            END; { case BitAnd }
END; { signonFilter }


- --Brian Bechtel     [e-mail]     "My opinion, not Apple's"


+++++++++++++++++++++++++++

From: [e-mail] (Charles B. Cranston)
Date: 10 Jul 92 23:06:19 GMT
Organization: UM Home for the Terminally Analytical

There's a somewhat simpler approach in chapter 10 of the
Macintosh Progamming Secrets second edition book.  It involves
keeping a second shadow TERec and doing something like this:

/* If keydown or autokey and not return or enter */

   key = theEvent->message & charCodeMask;

   if (key > kSpace) {
      theEvent->message &= ~charCodeMask;
      theEvent->message |= kBullet;
   }

   dialogTE = ( (DialogPeek) theDialog )->textH;
   (*pMirrorEditText)->selStart = (*dialogTE)->selStart;
   (*pMirrorEditText)->selEnd = (*dialogTE)->selEnd;
   TEKey(key,pMirrorEditText);

It then returns false so the modified event (made into bullet)
gets applied to the dialog's textedit but the real keystroke
gets applied to the pMirrorEditText textedit.  So the real
password is in pMirrorEditText at the end...

+++++++++++++++++++++++++++

From: [e-mail]  (Christophe Meessen)
Organization: Universite Catholique de Louvain (Belgium)
Date: Wed, 15 Jul 1992 09:48:31 GMT

In article <[e-mail]>, [e-mail] (Charles B.
Cranston) wrote:
>
> There's a somewhat simpler approach in chapter 10 of the
> Macintosh Progamming Secrets second edition book.  It involves
> keeping a second shadow TERec and doing something like this:
>
> /* If keydown or autokey and not return or enter */
>
>    key = theEvent->message & charCodeMask;
>
>    if (key > kSpace) {
>       theEvent->message &= ~charCodeMask;
>       theEvent->message |= kBullet;
>    }
>
>    dialogTE = ( (DialogPeek) theDialog )->textH;
>    (*pMirrorEditText)->selStart = (*dialogTE)->selStart;
>    (*pMirrorEditText)->selEnd = (*dialogTE)->selEnd;
>    TEKey(key,pMirrorEditText);
>
> It then returns false so the modified event (made into bullet)
> gets applied to the dialog's textedit but the real keystroke
> gets applied to the pMirrorEditText textedit.  So the real
> password is in pMirrorEditText at the end...

This is how I did. Glad to hear that it was suggested in Knaster's
Macintosh Progamming Secrets.

Your code is not complete. May be a sumary ?

I suggest the following more specific description.


The main idear is to have a shadow TEdit record beside the password
editable field. I call them 'passwdTEHdl' and 'shadowTEHdl'.

You need access to 'passwdTEHdl' and 'shadowTEHdl' to be able to handle
mouseEvt correctly. So instead of using a modal dialog in which I have no
access to the 'passwdTEHdl', I had to work with a non modal dialog with my
own event loop.  You'll see later why.

The 'passwdTEHdl' destRect and viewRect is set to the field rect, and the
'shadowTEHdl' destRect and viewRect is set to a same size rect but outside
the dialog portRect.

As in AppleShare, a LoginName field is associated to the password field. So
we have two visible editable fields. The field in which the next typed char
will be added is called the active field. We thus have a 'loginNameTEHdl'
and an 'activeField' variable telling if the active field is the
passwdField or the loginNameField.

To switch the active field from 'loginNameTEHdl' to 'passwdTEHdl' or
reverse we will use the tabKey or the mouse click.

Now to handle the events it's simple, we will use the following method

switch( theEvent.what ){

case autoKey:
case keyDown:
    <handle key down or autoKey event>

case mouseDown:
    <handle mouse down event>

case updateEvt:
    <handle update event>
}

Look at <handle key down or autoKey event> first.
This may be expressed like this:

key = (char)theEvent.message;

< handle default button keyboard shortcuts here >

if( activeField == loginNameField ){
   if( key == tabKey ) {
        TEDeactivate( loginNameTEHdl );
        TEActivate( passwdTEHdl );
        activeField = passwdField;
    } else {
       if( loginNameFilter( key ) )
            TEKey( key, loginNameTEHdl );
        else
            SysBeep( 1 );
    }
} else {
   if( key == tabKey ) {
        TEDeactivate( passwdTEHdl );
        TEActivate( loginNameTEHdl );
        activeField = LoginNameField;
    } else {
       if( passwdFilter( key ) ) {
           TEKey( key, shadowTEHdl );
           if( key > kSpace )
               key = kBullet;
           TEKey( key, passwdTEHdl );
        } else
            SysBeep( 1 );
    }
}

You may filter the key passed for loginName or passwd with the
loginNameFilter or the passwdFilter function returning true if the key is
accepted as valid and keep the edited string in a valid length.


Now let us <handle mouse down event>. We will first test in wich field the
user clicked. Then change the active field if required. And finaly, handle
the click.

A click in the password field requires to track the click on passwdTEHdl
which has the bullets and is the visible string. This is impossible to do
in a modal dialog. So this is the reason why I had to work with  a non
modal dialog.

GlobalToLocal( &theEvent.where );

if( ! PtInRect( theEvent.where, &theDialog.portRect ) ) {
    SysBeep( 1 );
    break;
}

< handle button click here >

extend = (theEvent.modifiers & shiftKey) == shiftKey;

if( PtInRect( theEvent.where, &loginNameRect ) ) {
   if( activeField == passwdField ) {
       TEDeactivate( passwdTEHdl );
       TEActivate( loginNameTEHdl );
       activeField = loginNameField;
   }
   TEClick( theEvent.where, extend, loginNameTEHdl );
}

if( PtInRect( theEvent.where, &passwdRect ) ) {
   if( activeField == loginNameField )
       TEDeactivate( loginNameTEHdl );
       TEActivate( passwdTEHdl );
       activeField = passwdField;
   }
   TEClick( theEvent.where, extend, passwdTEHdl );
   TESetSelect( (*(TEPtr *)passwdTEHdl)->selStart,
                (*(TEPtr *)passwdTEHdl)->selEnd, shadowTEHdl );
}


BTW, this way of handling passwd input has another advantage. In modal
dialog with more then one editable fields, when a field becomes inactive,
the field string is drawn one point higher. The reason for this is another
debate. But now we can avoid this feature.


To <handle update event>, nothing is simpler,

BeginUpdate( theDialog );

DrawDialog( theDialog );

< frame default button here >

PenSize( 1, 1 );

EraseRect( &loginNameRect );
FrameRect( &loginNameRect );
TEUpdate( &loginNameRect , loginNameTEHdl );

EraseRect( &passwdRect );
FrameRect( &passwdRect );
TEUpdate( &passwdRect, passwdTEHdl );

EndUpdate( theDialog );




Bien cordialement,

                           Christophe MEESSEN

+++++++++++++++++++++++++++

From: [e-mail] (Dana S Emery)
Date: 24 Jul 92 08:13:28 GMT
Organization: Personal

In article <[e-mail]>, [e-mail] (David W. Berry) wrote:

> Simplest approach I've seen is to create a FONT with nothing but bullet's
> in it and use it for the font for the TERec.  Saves all kind's of hassles
> and kludges and works almost anywhere.

Unfortunatly, spaces are not printed from the FONT/NFNT, so they will not
echo as a bullet. I discovered this the hard way while developing a 'show
invisibles' capability, and decided to use sicns for the invisibles in
stead of a private font.  Since some passwords allow space as a character,
this is not a foolproof technique.

- --

Dana S Emery <[e-mail]>

+++++++++++++++++++++++++++

From: [e-mail] (David W. Berry)
Date: 17 Jul 92 21:05:07 GMT
Organization: Greenwing Enterprises

In article <[e-mail]> Charles B. Cranston,
[e-mail] writes:
>There's a somewhat simpler approach in chapter 10 of the
>Macintosh Progamming Secrets second edition book.  It involves
>keeping a second shadow TERec and doing something like this:
>
Simples approach I've seen is to create a FONT with nothing but bullet's
in it and use it for the font for the TERec.  Saves all kind's of hassles
and kludges and works almost anywhere.

---------------------------

From: [e-mail] (James Edwards)
Subject: DLOG stuff....
Organization: George Mason University, Fairfax, Va.
Date: Thu, 16 Jul 1992 15:09:31 GMT

This is probably too simple, but I haven't been able to get it to work.
I have an about box for my program is entirely filled with a picture
item.  I want to put the continue button on top of the picture, but when
I do it, you can't select it, and the program is stuck.  I tried
renumbering the items so that it was drawn after the picture, but that
didn't work either.  Do I have to emulate a button, and just check for
the mouse click in a certain RECT?  Or is there an elegant way to do
this?  Thanks in advance!

Jimi


+++++++++++++++++++++++++++

From: [e-mail] (Jerry Wilcox)
Date: 16 Jul 92 17:34:39 GMT
Organization: University of California

In article <[e-mail]> [e-mail]
(James Edwards) writes:
>This is probably too simple, but I haven't been able to get it to work.
>I have an about box for my program is entirely filled with a picture
>item.  I want to put the continue button on top of the picture, but when
>I do it, you can't select it, and the program is stuck.  I tried
>renumbering the items so that it was drawn after the picture, but that
>didn't work either.  Do I have to emulate a button, and just check for
>the mouse click in a certain RECT?  Or is there an elegant way to do
>this?  Thanks in advance!
>
>Jimi
>
>
I don't know how elegant it is, but I put up my About dialogs from a routine
which does its own event loop, and I clear the dialog and return to my main
event loop when any key is pressed or when the mouse is clicked anywhere on the
screen.

***********************************************************************
* Hey! If UC wanted me to speak for it - I'd have a different job!    *
*   Jerry Wilcox, IS&C, UC Office of the President, Oakland, CA       *
* [e-mail] === [e-mail] === CIS 72760,2401  *
***********************************************************************

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 19 Jul 92 07:53:45 GMT

I like to make the DITL for the DLOG consist of only one item: a PICT
resource that covers the entire dialog.  Make sure the item is enabled.
Then, your about code looks like this (clean and concise):

            dp = GetNewDialog( 131, nil, (WindowPtr)-1L );
            if( dp ) ModalDialog( nil, &i );
            DisposeDialog( dp );

Dunno why more people don't use this technique...  If you want to be fancy,
you might pass a filterProc that will check for hitting keys to dismiss
the dialog also --  but that's left as an excersice for the reader.

    - Scott

6000 dollars of Macintosh Mayhem nearly destroyed by 25 cents of milk.

+++++++++++++++++++++++++++

From: John Lacey <[e-mail]>
Organization: Computer Science, Indiana University
Date: Sun, 19 Jul 1992 21:20:54 -0500

[e-mail] (Scott Bronson) writes:

> I like to make the DITL for the DLOG consist of only one item: a PICT
> resource that covers the entire dialog.  Make sure the item is enabled.
> [...]
> Dunno why more people don't use this technique...  If you want to be fancy,
> you might pass a filterProc that will check for hitting keys to dismiss
> the dialog also --  but that's left as an excersice for the reader.

This is nearly my favorite method as well.  I make sure everything is
*disabled*, and write a filter proc that returns

    theEvent->what == mouseDown || theEvent->event == keyDown

Strictly, it is not necessary that everything be disabled.  From what
I have seen, from others and disassembling applications, this *is* a
pretty popular way to do this.

P.S.  For what it's worth, I have come to standard windows for the
about box.  Makes it less obtrusive, and makes the ambiguity and
inconsistency of dismissing the splash screen a non-issue.

- --
John Lacey        ``What's wrong with my style is not a lack of expressiveness
                    or lucidity, but vulgarity.''                --G. H. Hardy

+++++++++++++++++++++++++++

From: [e-mail] (Scott Bronson)
Date: 22 Jul 92 05:30:28 GMT

In <scott.711532425@mcl> [e-mail] (Scott Bronson) writes:

>I like to make the DITL for the DLOG consist of only one item: a PICT
>resource that covers the entire dialog.  Make sure the item is enabled.
>Then, your about code looks like this (clean and concise):

>            dp = GetNewDialog( 131, nil, (WindowPtr)-1L );
>            if( dp ) ModalDialog( nil, &i );
>            DisposeDialog( dp );

>Dunno why more people don't use this technique...  If you want to be fancy,
>you might pass a filterProc that will check for hitting keys to dismiss
>the dialog also --  but that's left as an excersice for the reader.
I'll tell you why more people don't use my EXACT technique.  It's
got a glaring bug that I didn't notice until just now.  I'm suprised
no one else on the net caught me doing this.

Do you see the bug?  The above code should read:

           dp = GetNewDialog( 131, nil, (WindowPtr)-1L );
           if( dp ) {
               ModalDialog( nil, &i );
               DisposeDialog( dp );
           }


A rather embarassed...

    - Scott

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 22 Jul 92 20:24:24 GMT
Organization: U. C. Berkeley Open Computing Facility

>In <scott.711532425@mcl> [e-mail] (Scott Bronson) writes:
>Do you see the bug?  The above code should read:
>
>           dp = GetNewDialog( 131, nil, (WindowPtr)-1L );
>           if( dp ) {
>               ModalDialog( nil, &i );
>               DisposeDialog( dp );
>           }
>
>
>A rather embarassed...
>
>    - Scott

Don't feel so bad Scott, you would have never been burned anyway.  Page 413 of
Inside Mac has a warning stating:

"If either the dialog template resource or the item list cannot be read, the function result is undefined."

I have never gotten nil as a result from GetNewDialog.  As far as I know, Apple hasn't bothered to fix the call yet.  Paranoid programmers (like myself) put
envelope routines around GetNewDialog and Alert.  The routine reads in both
the DITL and DLOG (or ALRT) resource and makes sure they're non-purgeable.

Then it calls GetNewDialog.  Window centering code that observes the system 7 flags under systm 6 can be inserted here as well.

Anybody out there know why apple likes to make our lives just a bit more interesting by not retuning error codes for the above routines and being so wierd about
GetResource ?  It really pisses me off.

Hat to ramble, but my newsposter won't allow me to type less than I quote.

piss.

- -E Wylie
.

---------------------------

From: [e-mail] (Michael Kamprath)
Subject: Using CODE rescource files
Date: Thu, 16 Jul 92 14:31:03 EDT
Organization: University of Michigan

I would like to be able to build CODE rescource files, and then load them
by my program in order to evaluate some data.  I am using THINK C 5.0.
The THINK manual describes how to write a CODE rescource, but not how
to employ it.

What I want my program to be able to do: The user open a CODE file containing
the function they wish to use, the program then pass the function some
data, and the function (in theCODE rescource) return a result.  The reason I
want to do this is because I want the user to be able to write the function
that the program uses.

Thanks for any help

Michael Kamprath
[e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (David Phillip Oster)
Organization: Whole Earth 'Lectronic Link
Date: Thu, 23 Jul 1992 08:50:23 GMT

Use think C to build a resourc with code in it, say type 'mCod'm id = 128.
if it has a main procedure
pascal vvoid main(short verb, long *result, ListHandle lh);

then you call it form your main program with:
    Handle    h;
    SignedByte    state;
    long        res;

    if(NIL != (h = GetResource('mCod', 128))){
        state = HGetState(h);
        HLock(h);
        CallPascal( 3, &res, lh, *h);
        HSetState(h, state);
    }
For a main that is a C procedure, say:
typedef void (*CodeResType_)(short verb, long *result, ListHandle lh);

then, instead of the CallPascal line above, say:
(* (CodeResType) *h)( 3, &res, lh);

---------------------------

From: [e-mail] (J. S. Greenfield)
Subject: Moving to the foreground after receiving an 'odoc' from the Finder
Date: 20 Jul 92 23:53:34 GMT
Organization: Syracuse University, CIS Dept.


What is the standard technique to insure that your application is in the
foreground after receiving an 'odoc' event from the finder?

I have an application (which does not recieve suspend/resume events) which
brings up a custom get file after receiving an 'odoc' event.  If there are
some finder windows open, the get file dialog will occasionally appear
*behind* the finder windows, initially.  It then moves to the front, but
the dialog window is left empty.

Can anyone provide me with references to relevant portions of IM or the
technical notes?


Thanks in advance.


- --
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 21 Jul 92 16:12:51 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (J. S. Greenfield) writes:
>
>What is the standard technique to insure that your application is in the
>foreground after receiving an 'odoc' event from the finder?
>
>I have an application (which does not recieve suspend/resume events) which
                        ^^^^^ ^^^^ ^^^ ^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^
This is the root of your problem.  If you accept high-level events, you also
_must_ accept OS events (suspend/resume, etc).

>brings up a custom get file after receiving an 'odoc' event.  If there are
>some finder windows open, the get file dialog will occasionally appear
>*behind* the finder windows, initially.  It then moves to the front, but
>the dialog window is left empty.

If you want to be absolutely sure you're in front, you can call
_SetFrontProcess (I think that's the name) with your own process serial #.
However, I suspect that if you handle your suspend/resume events by the
book, the other problems should "factor out".

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Christopher Suley)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Tue, 21 Jul 1992 17:46:31 GMT

[e-mail] (J. S. Greenfield) writes:
>
>What is the standard technique to insure that your application is in the
>foreground after receiving an 'odoc' event from the finder?
>
>I have an application (which does not recieve suspend/resume events) which
>brings up a custom get file after receiving an 'odoc' event.  If there are
>some finder windows open, the get file dialog will occasionally appear
>*behind* the finder windows, initially.  It then moves to the front, but
>the dialog window is left empty.
>
>Can anyone provide me with references to relevant portions of IM or the
>technical notes?
>

In _Macintosh Programming Secrets, 2e_, they call EventAvail 3 times when
the program starts up to bring it to the front.  They say that this is the
"standard" way to bring a program to the front under MultiFinder.
- --
|}-{}-{}-{}-{}-{}-{}-{}-{}-{|
{} Christopher S. Suley    {}  "do you expect me to talk?"
{} [e-mail]   {}  "no, mr. bond, i expect you to die."
|}-{}-{}-{}-{}-{}-{}-{}-{}-{|

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 21 Jul 92 21:56:59 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.uchicago.edu> [e-mail] (JohnC) writes:

   This is the root of your problem.  If you accept high-level events, you also
   _must_ accept OS events (suspend/resume, etc).

This is mostly true. You also should make sure that you
never post Alerts in the background, instead, do something
like:

    EnsureInFront ( ) ;
    Alert ( ... ) ;

where EnsureInFront returns if you ARE in front, or posts a
notification and waits until you get into front if you're
not.

   If you want to be absolutely sure you're in front, you can call
   _SetFrontProcess (I think that's the name) with your own process serial #.
   However, I suspect that if you handle your suspend/resume events by the
   book, the other problems should "factor out".

DO not change the front applications forcibly. Don't. No.
(Well, I have a reason for doing it, but YOU shouldn't :-)

You should call AEInteractWithUser when you "need" to get
to the front and can't resort to posting a notification and
waiting.

AEInteractWithUser is safe to call even if you're not handling
an apple event, though, I was told by one of the engineers at
the Apple Events panel at the WWDC. Cool. So AEInteractWithUser
is preferred to SetFrontProcess.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds
### and weird keyboard behaviour when you press the shift key repeatedly.

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 21 Jul 92 22:06:42 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Christopher Suley) writes:

   In _Macintosh Programming Secrets, 2e_, they call EventAvail 3 times when
   the program starts up to bring it to the front.  They say that this is the
   "standard" way to bring a program to the front under MultiFinder.


No, it's the standard way of bringing the app to the
front WHEN BEING LAUNCHED under MultiFinder. Big difference !
Calling EventAvail will NOT switch layers by itself.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds
### and weird keyboard behaviour when you press the shift key repeatedly.

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Tue, 21 Jul 1992 23:11:24 GMT

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>.uchicago.edu> [e-mail] (JohnC) writes:
>   If you want to be absolutely sure you're in front, you can call
>   _SetFrontProcess (I think that's the name) with your own process serial #.
>   However, I suspect that if you handle your suspend/resume events by the
>   book, the other problems should "factor out".
>
>DO not change the front applications forcibly. Don't. No.
>(Well, I have a reason for doing it, but YOU shouldn't :-)
>
>You should call AEInteractWithUser when you "need" to get
>to the front and can't resort to posting a notification and
>waiting.

Point taken.  Mea culpa.


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Christopher Suley)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
Date: Wed, 22 Jul 1992 18:56:14 GMT

[e-mail] (Jon W{tte) writes:
>> I wrote:
>
>   In _Macintosh Programming Secrets, 2e_, they call EventAvail 3 times when
>   the program starts up to bring it to the front.  They say that this is the
>   "standard" way to bring a program to the front under MultiFinder.
>
>No, it's the standard way of bringing the app to the
>front WHEN BEING LAUNCHED under MultiFinder. Big difference !
>Calling EventAvail will NOT switch layers by itself.
>

Oops. My bad. I never did well in reading comprehension tests anyway. ;)

I have a question.  In _Inside Macintosh_, the Memory Manager chapter in
Volume 2 I think, there is a warning that you shouldn't do anything to a
handle unless the current zone is the one in which the handle resides.

I have an application that reads the data out of a handle I store in the
system heap.  It's never had a problem (the data has always been correct),
but now I'm concerned.

It's not a big problem to add GetZone, SetZone( SystemZone() ) calls, but
I was just wondering why that warning was there.


- --
|}-{}-{}-{}-{}-{}-{}-{}-{}-{|
{} Christopher S. Suley    {}  "do you expect me to talk?"
{} [e-mail]   {}  "no, mr. bond, i expect you to die."
|}-{}-{}-{}-{}-{}-{}-{}-{}-{|

+++++++++++++++++++++++++++

From: [e-mail] (J. S. Greenfield)
Date: 22 Jul 92 04:34:51 GMT
Organization: Syracuse University, CIS Dept.

In article <[e-mail]> [e-mail] writes:
>>
>>What is the standard technique to insure that your application is in the
>>foreground after receiving an 'odoc' event from the finder?
>>
>>I have an application (which does not recieve suspend/resume events) which
>                        ^^^^^ ^^^^ ^^^ ^^^^^^^ ^^^^^^^^^^^^^^ ^^^^^^
>This is the root of your problem.  If you accept high-level events, you also
>_must_ accept OS events (suspend/resume, etc).

But this is not correct.  The SIZE resource has a bit to indicate whether
the application receives suspend/resume events.  Since this application
does not manipulate any scrap or manipulate any windows (other than modal
dialogs), it has no need for suspend/resume events.

Anyway, even if they were sent, I don't mask them out.  They just would not
produce any response from my application.


>>brings up a custom get file after receiving an 'odoc' event.  If there are
>>some finder windows open, the get file dialog will occasionally appear
>>*behind* the finder windows, initially.  It then moves to the front, but
>>the dialog window is left empty.
>
>If you want to be absolutely sure you're in front, you can call
>_SetFrontProcess (I think that's the name) with your own process serial #.
>However, I suspect that if you handle your suspend/resume events by the
>book, the other problems should "factor out".

Actually, several individuals pointed me to the proper technique when handling
apple events, which is to call AEInteractWithUser.  This routine checks both
the server's and client's specification for allowed interaction in processing
the event, and will call the notification manager, if necessary, in order to
request that the user move the server application to the foreground.

(See IM VI, 6-51 through 6-54.)

In my case, this is not necessary--the call simply holds up my application
until it moves to the foreground, as it will normally do since 'odoc' events
from the Finder allow the server to interact (and the Finder seems to
undertake to move the server to the foreground, itself).


- --
J. S. Greenfield                                         [e-mail]
(I like to put 'greeny' here,
but my d*mn system wants a
*real* name!)                        "What's the difference between an orange?"

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 23 Jul 92 17:36:45 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (JohnC) writes:
> If you accept high-level events, you also _must_ accept OS events
> (suspend/resume, etc).

I have a counterexample to this claim: Adobe Premiere 1.0. Here are the
settings of some of its "SIZE" resource bits:

    accept suspend events: no
    does activate on FG switch: no
    32-bit compatible: yes
    high-level event aware: yes

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Does "future-proof" strike you as a phrase that can be taken two ways?

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Organization: The Royal Society for Putting Things on Top of Other Things
Date: Thu, 23 Jul 1992 16:15:26 GMT

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail] (JohnC) writes:
>> If you accept high-level events, you also _must_ accept OS events
>> (suspend/resume, etc).
>
>I have a counterexample to this claim: Adobe Premiere 1.0. Here are the
>settings of some of its "SIZE" resource bits:
>
>    accept suspend events: no
>    does activate on FG switch: no
>    32-bit compatible: yes
>    high-level event aware: yes

I was too emphatic (read: "incorrect") when I said "_must_".  However, I
still maintain that there's no good reason for an application written after
1986 to _not_ accept suspend/resume events.  They're just too easy to support,
and at the least alleviate the need for the OS to waste machine cycles on the
infamous Switcher/Multifinder desk accessory switching fakeout.

Hmm, come to think of it, what I may have been imperfectly recalling was
the documentation stating that if you set the activate-on-FG bit then you
should also set the accept-suspend-events bit.

Anyway...

- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g++ k s++ e+ h- pv    |         Chicago, IL  60637

---------------------------

End of C.S.M.P. Digest
**********************